Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 003 / db3work.arc / DB3WORK.TXT

Wrap

Text File | 1986-03-28 | 52.1 KB | 1,578 lines

- Locating dBASE III Usage Tips - ( from the Source - Ashton Tate SIG- ATSIG ) 63 item(s) found for ALL title: ASCII VALUES RETURNED IN RESPONSE TO WAIT version: DR date: 10 Mar 1986 text: The ASCII codes stored in response to the WAIT command are different in the Developer's Release of dBASE III than in versions 1.0 and 1.1. The code values returned from function keys in the Developer's Release are larger by one. The following table shows the codes returned from each version. Developer's Versions Key Release 1.0 and 1.1 Function === =========== =========== ======== F1 0 0 HELP F2 255 254 ASSIST F3 254 253 LIST F4 253 252 DIR F5 252 251 DISP STRU F6 251 250 DISP STAT F7 250 249 DISP MEMO F8 249 248 DISPLAY F9 248 247 APPEND F10 247 246 EDIT SPACE 32 32 SPACE BACKSPACE 127 127 All other keys that send non-display characters including Alt, Ctrl, and shifted keypad characters, return an ASCII 0. title: SET ORDER TO WITH RECORD POINTER NEAR BOTTOM OF FILE version: DR date: 10 Mar 1986 text: SETting ORDER TO will take an inordinate amount of time to execute if the record pointer is at or near the bottom of the database file. SET ORDER TO takes six to ten times longer than to SET INDEX TO the same order and restore the record pointer to its previous position. title: SET HISTORY TO NON-NUMERIC version: DR date: 10 Mar 1986 text: SET HISTORY TO accepts only numeric chararcters reading from left to right until a nonnumeric character is encountered. Therefore, the commands: SET HISTORY TO 1,000,000 SET HISTORY TO 1.9 are functionally identical to: SET HISTORY TO 1 title: LINE LENGTH LIMIT FOR HISTORY version: date: 10 Mar 1986 text: The maximum command line length in dBASE III is 254 characters. HISTORY reserves 240 characters (three lines of the screen) for each command line. Commands longer than 240 characters are truncated when recorded in HISTORY. This occurs whether the command is recorded through SET HISTORY ON or SET DOHISTORY ON. title: CTOD() WITH INVALID STRING ARGUMENT version: 10 11 date: 10 Mar 1986 text: The CTOD() function will accept any string as an argument and return a date. If the string is not a valid date string within the format of SET DATE, the results of the CTOD() function will be unpredictable. The CTOD() function converts any literal that contains only nonnumeric characters to 11/30/99. For example: ? CTOD('HALLOWEEN') 11/30/99 The CTOD() function converts strings containing numeric and nonnumeric characters not in the format selected with SET DATE to a date without producing an error message. For example: ? CTOD(`12//12') 11/30/12 ? CTOD('he12/12') 11/30/11 ? CTOD('12/12/he') 12/12/00 The Developer's Release of dBASE III, however, returns a blank date if the CTOD() function is used with an incorrect value. title: BLANK IF ZERO version: 10 11 DR date: 10 Mar 1986 text: Sometimes you may wish to display a blank instead of a zero for an empty numeric variable. If you are using an @..SAY command to display the numeric variable, use the @Z function of the PICTURE clause. For example, number = 0 @ 10,10 SAY number PICTURE "@Z 999" If however, you are displaying the numeric variable with a non-full screen command such as LIST, ?, or the REPORT FORM, you will have to use an expression to suppress the zero display. To replace a zero field value with a blank, first change the field contents to a character string using the STR() function. Then use the SUBSTR() and AT() functions to replace the zero string with a blank string. The following expression can be used to accomplish this: SUBSTR(SPACE(5)+STR(Numfield,5,2),AT(STR(Numfield,5,2), ' 0.00'+STR(Numfield,5,2)),5) ^ ^-------- This value and the value | of SPACE() must equal | the length of the field. | ------------------------------ The length of this clause must also be the length of the field. If you have the Developer's Release, use the TRANSFORM() function and the @Z function of the PICTURE clause as you would with the @..SAY..PICTURE command. For example, number = 0 ? TRANSFORM( number, "@Z 999" ) title: FORMAT FILE MUST NOT BE ENCRYPTED version: DR date: 10 Mar 1986 text: A format file must remain unencrypted, or be worked into the .SRC file to be utilized by dBRUN. The documentation for RunTime+ does not mention that an unencrypted format (.FMT) file may be accessed with the SET FORMAT TO command. In fact, dBRUN will process only an unencrypted format file with this command. title: ON KEY DOES NOT INTERRUPT COMMAND BEING PROCESSED version: DR date: 10 Mar 1986 text: If you have set the ON KEY command and are executing any command that takes some time to process, such as LIST or REPORT FORM, pressing a key will not interrupt the command being executed. Instead the key pressed will be stored in the typeahead buffer and ON KEY will execute when that command is finished. title: POSSIBLE TO SET RANGE FROM UPPER TO LOWER LIMIT version: 10 11 DR date: 10 Mar 1986 text: It is possible to set a RANGE from the upper limit to the lower limit rather than from the lower limit to the upper. For example: mem = 0 @ 2,2 GET mem PICTURE "9" RANGE 9,1 Although this is not trapped as an error, no entry can meet this RANGE specification. Placing the higher value as the first argument creates an impossible condition by requiring that the entry be both greater than or equal to the upper limit and less than or equal to the lower limit. title: LOCATE WHILE version: 10 11 date: 10 Mar 1986 text: Page 4-73 of the dBASE III Reference Manual for version 1.1 __________________________ gives the syntax of the LOCATE command as: LOCATE [<scope>] FOR/WHILE <condition> However, the WHILE clause of the LOCATE command is not implemented in versions of dBASE III earlier than the Developer's Release. Use of the command: LOCATE WHILE <condition> will produce "Syntax error." Attempting to use the FOR and WHILE clauses together will give, "FOR and WHILE cannot both be specified." In the Developer's Release the WHILE clause is fully implemented, incling the simultaneous use of the FOR and WHILE clauses. title: BLANK LINES IN LABEL FORM version: 10 11 DR date: 10 Mar 1986 text: If you are defining a formatted LABEL FORM, you may want to include blank lines for spacing. The LABEL FORM, however, suppresses all blank lines whether you have defined an expression whose contents are blank or whether the line in your definition is blank. To create a blank line, enter into the line contents area the expression CHR( 255 ). This will cause the LABEL FORM to recognize the line as nonblank and print the ASCII character represented by CHR( 255 ), which has no display value. title: FIND AND SEEK WILL BOTH PERFORM CONCATINATION version: 10 11 DR date: 10 Mar 1986 text: The FIND command performs string concatenations, although it is not documented as having this capability. For example: FIND 'P'+'A' will find "PA." FINDing on a numeric key will FIND an expression up to a special character. The following examples of the FIND command will all FIND the record with "755" in the key. FIND 755 / 3 FIND 755 * 3 FIND 755 - 3 title: FIND WILL IGNORE LEADING SPACES WHEN FINDING A LITERAL version: 10 11 DR date: 10 Mar 1986 text: The FIND command will ignore leading blanks when searching a literal string. The results of the commands, FIND A FIND A are identical. For this reason the commands, FIND &memvar FIND "&memvar" are not interchangeable when the string being sought has leading blanks. For example: STORE " A" TO memvar FIND &memvar <-- will find "A" FIND "&memvar" <-- will find " A" title: LAST UPDATE DATE AND TIME version: 10 11 DR date: 10 Mar 1986 text: To get the date of last update for the currently SELECTed database file in the Developer's Release of dBASE III, use the LUPDATE() function. LUPDATE() returns the date of last update as a value of date type. dBASE III versions 1.0 and 1.1 currently do not have a function that returns the date of last update for the SELECTed database file. To get the date of last update in these versions of dBASE III, use the PC/MS-DOS command DIR, and import the results into dBASE III. The basic algorithm is as follows: 1. Create or have available a general purpose database file called Util.DBF. Util.DBF has one field called Util_line which is character type and has a length of 80. 2. RUN the PC/MS-DOS command DIR with the name of your database file, piping the result into a text file entitled Util.TXT. 3. APPEND the text file Util.TXT into the database file Util.DBF. 4. Assign to a memory variable the date of last update from Util.DBF for your database file. The code that will get the last update of the currently SELECTed database file is as follows: SET SAFETY OFF RUN DIR <Yourfile>.DBF > Util.TXT USE Util ZAP APPEND FROM Util SDF lupdate = SUBSTR( Util_line, 25, 8 ) luptime = SUBSTR( Util_line, 34, 6 ) USE SET SAFETY ON RETURN title: GET CURRENT DIRECTORY version: 10 11 DR date: 10 Mar 1986 text: dBASE III has no facility to get the name of the current directory. To get it you must RUN the PC/MS-DOS command CD and import the results into dBASE III. The basic algorithm is as follows: 1. Create or have available a general-purpose database file called Util.DBF. Util.DBF has one field called Util_line which is character type and has a length of 80. 2. RUN the PC/MS-DOS command CD, piping the result into a text file entitled Util.TXT. 3. APPEND the text file Util.TXT into the database file, Util.DBF. 4. Assign to a memory variable the name of the current DOS directory from Util.DBF. The code that will execute this algorithm is as follows: SET SAFETY OFF RUN CD > Util.TXT USE Util ZAP APPEND FROM Util SDF currdir = TRIM( Util_line ) SET SAFETY ON RETURN title: GET DISKSPACE version: 10 11 DR date: 10 Mar 1986 text: In the Developer's Release use the DISKSPACE() function to get the amount of space left on the currently logged drive. The DISKSPACE() will return the number of free bytes on the default drive as a numeric value . dBASE III versions 1.0 and 1.1 do not have a function to return the amount of space left on the default drive. So, to get the amount of diskspace in these versions, use the PC/MS-DOS utility CHKDSK and import the results into dBASE III. The basic algorithm is as follows: 1. Create or have available a general purpose database file called Util.DBF. Util.DBF has one field called Util_line which is character type and has a length of 80. This database file will be useful for any of these kinds of survey operations into PC/MS-DOS. 2. RUN CHKDSK including the designator of the drive for which you want the space statistic for, and pipe the result into a text file entitled Util.TXT. Piping is a PC/MS-DOS capability that allows the results of a program to be sent into a text file. It is very useful for passing parameters between programs when there is no formalized interface. The syntax is: <DOS commmand> > <result text file> _____ DOS piping symbol For more information on this capability, consult your PC/MS-DOS reference manual. 3. APPEND the text file, Util.TXT, into the database file, Util.DBF. 4. Assign to a memory variable the number of free bytes on the specified drive from Util.DBF. This operation requires that you GOTO the record that contains the free disk space information and then extract the number of bytes from the field using the SUBSTR() function. The following is a LIST of Util.DBF with the results of a CHKDSK reporG ;hen APPENDed into a {xbase file, the first and last records are always blank. Records 2 through 6 contain statistics about the currently logged disk drive. Note that this is the currently logged DOS drive and not the DEFAULT drive SET in dBASE III. Records 8 and 9 contain statistics about the memory configuration of your computer. The number of bytes for each attribute of the drive and memory occupy positions 1 through 9 in the database field, Util_line. Record# 1 2 9965568 bytes total disk space 3 155648 bytes in 4 hidden files 4 90112 bytes in 22 directories 5 6000640 bytes in 397 user files 6 3719168 bytes available on disk 7 8 524288 bytes total memory 9 122480 bytes free 10 The code that will get the the number of free bytes on the specified disk drive is as follows: SET SAFETY OFF RUN CHKDSK > Util.TXT USE Util ZAP APPEND FROM Util SDF GO 6 diskspace = STR( SUBSTR( Util_line, 1, 9 ), 9 ) USE SET SAFETY ON RETURN title: FUNCTION KEYS version: 10 11 DR date: 10 Mar 1986 text: F1 toggles the cursor control menu on and off in the following full screen edit modes. APPEND EDIT MODIFY LABEL MODIFY STRUCTURE BROWSE CHANGE MODITY REPORT title: FIND AND SEEK version: 10 11 DR date: 10 Mar 1986 text: FIND and SEEK are both used to move the record pointer of an indexed database to the first instance of the index key that matches the search argument. FIND searches on a literal character string while SEEK searches on an expression the value of which may be character, date, or numeric. The proper choice of command is related to the context and data type of the index key. Generally, FIND will only be used to search for a literal character string and SEEK for all other searches. The following are some typical cases: (1) You have an index key that is character and are working from the dot prompt: . FIND Lee {or} . SEEK "Lee" (2) You have an index key that is numeric or date and are working from the dot prompt: . SEEK 1250 . SEEK CTOD('12/12/85') (3) You are working within a command file and are initializing a memory variable as a search key: STORE SPACE(10) TO skey @ 10,10 SAY 'Enter value to search for' GET skey READ SEEK skey (4) You have a database field that is character, Code, and the contents are numeric digits and right-justified: ACCEPT 'Enter code to search for' to skey SEEK SPACE(LEN(Code) - LEN(skey)) + skey (5) You are working with several databases and want to search for a key value in the current work area using a field variable from a non-active area with an alias name: SELECT 1 USE File1 INDEX File1 SELECT 2 USE File2 INDEX File2 SELECT File1 SEEK File2->Field1 title: SET COLOR version: 10 11 date: 10 Mar 1986 text: (1) To get enhanced video to be black on black, use the command SET COLOR TO x/y,0+/0. Black on black is frequently used to allow user input without displaying the characters on the screen, as with entry of a password. (2) The command: SET COLOR TO ,<cr> will produce black on black, even if there is no space after the comma. (3) The asterisk (*) used with the SET COLOR command allows you to have blinking characters on the screen. The asterisk must be used in conjunction with a color parameter. For example: SET COLOR TO 6*/1,7/4,6 or: SET COLOR TO GR*/B,W/R,GR title: SET ALTERNATE TO version: 10 11 date: 10 Mar 1986 text: dBASE III will not send a linefeed (that is, CHR(10)) to an alternate file (Word Perfect looks for this linefeed character in its mail merge program). The following command file: SET ALTERNATE TO x SET ALTERNATE ON ?? "first LF" ?? CHR(10) ?? "second LF" SET ALTERNATE OFF CLOSE ALTERNATE will generate the following test file: first LFsecond LF As you can see, there is no linefeed in the file. title: RUN COMMAND version: 10 11 DR date: 10 Mar 1986 text: You can get the equivalent to Framework's DOS Access in dBASE III by issuing RUN COMMAND. This will leave you at the DOS operating system level and will allow you to enter any DOS commands. To get back to the dBASE III dot prompt, type EXIT. title: RUN (OR !) version: 10 11 DR date: 10 Mar 1986 text: The RUN command requires that COMMAND.COM be in the boot drive or the directory indicated by SET COMSPEC. Otherwise, the incorrect error message "Insufficient memory" is displayed. title: ROW(), COL() version: 10 11 DR date: 10 Mar 1986 text: After a READ, the ROW() function always returns 24; however, the COL() function does not change. For example: SET TALK OFF var = SPACE(2) @ 5,40 GET var ? ROW(), COL() <--- This returns 6 and 3. READ ? ROW(), COL() <--- This returns 24 and 3. title: RESERVED WORDS version: 10 11 DR date: 10 Mar 1986 text: Page 1-138 of the tutorial in the first edition of the manual uses a sample routine which creates a memory variable with the name 'continue.' Since this is a reserved word, dBASE III will give the message, "No database in USE, enter filename." dBASE III is assuming you intend to CONTINUE on a LOCATE command. This will only happen if you use the <variable> = <value> form of assignment; dBASE III will execute correctly when you use the STORE <value> TO <variable> form. Other words that will not work with the first syntax are: AVERAGE, COUNT, and SUM. title: RESERVED DEVICE NAMES IN MS-DOS version: 10 11 DR date: 10 Mar 1986 text: The MS-DOS manual specifies that certain names have a special meaning to MS-DOS. Do not use these reserved device names as dBASE III filenames: CON, AUX, COM1, COM2, LPT1, PRN, LPT2, LPT3, or NUL. This applies to database files, index files, command files, format files, or form files. Various error messages will result when files with any of these names are accessed. title: REPORT FORM version: 10 11 date: 10 Mar 1986 text: The semicolon is not documented as functioning as a Carriage Return/Line-Feed in certain parts of REPORT FORMs. title: RANGE version: 10 11 DR date: 10 Mar 1986 text: The dBASE III Reference Manual states that RANGE may be used to specify lower and upper bounds for date variables, but does not clarify that the arguments of the RANGE clause involving literal dates must be in the form, CTOD("mm/dd/yy"). For example: @ 10,10 GET Mdate RANGE CTOD("01/01/85"), CTOD("01/01/86") title: REPORT FORM <FILENAME> PLAIN version: 10 11 DR date: 10 Mar 1986 text: The PLAIN option of the REPORT FORM command will cancel out the HEADING option when these two are used in the same command line. Therefore, do not use these two options in the same command. For example, the following command line will not print the HEADING "Week of May 6, 1985": REPORT FORM Wksales PLAIN HEADING "Week of May 6, 1985" TO PRINT title: REPORT FORM, MODIFY REPORT version: 10 11 date: 10 Mar 1986 text: (1) The report generator will right-justify field headings for numeric fields when the report is run. (2) If the PLAIN clause is specified with REPORT FORM TO PRINT, no page ejects occur. The report prints through to the end without page breaks. (3) MODIFY REPORT will allow the number of decimal places to be changed from the default. If this is done and the report is run, everything is as expected. However, if the report is modified again, the number of decimal places reverts to the default when the cursor reaches the "# decimal places" field. (4) Although not documented in the manual or in the cursor control menu, Ctrl-N inserts a column in a report being created or modified. However, its counterpart (Ctrl-U which deletes a column) is documented and included in the help menu. title: REPORT FORM HEADING version: 10 11 DR date: 10 Mar 1986 text: There appears to be some confusion about the use of the HEADING option to the REPORT FORM command. The argument of the HEADING statement is a character expression and, therefore, can contain any combination of memory variables, field variables including aliases, and functions that evaluate to a value of character type. This means that macro substitution is not necessary to in order to use variable data for the REPORT FORM in question. As a typical example: * ---Set up header string. title = "Sample Report Number 1" *---Run the report. REPORT FORM YourRpt HEADING title If the HEADING argument is a field variable from the database file being REPORTed on, the value of the HEADING will be the field value from the record being pointed to when the REPORT FORM is invoked. For example, if the current record number is 5 and a REPORT FORM is run with no scope, the HEADING value is set from record 5 and then the record pointer is reset to the top of file. The ability to use a database field as the HEADING argument presents some interesting possibilites. Suppose you have a master client and transaction file. You wish to have a transaction listing for a particular client with that client's name at the top of the REPORT FORM. The transactions database file is INDEXed in client number order. * ---Open database files. SELECT 1 USE Client SELECT 2 USE Transaction INDEX Transaction SELECT Client * ---Get the client to report on. LOCATE FOR Name = "Smith" * ---Report client's transactions. SELECT Transaction REPORT FORM Transaction HEADING Client->Name; WHILE Number = Client->Number title: REPORT FORM--DATES version: 10 11 DR date: 10 Mar 1986 text: If you have a date-oriented report and you need to have it grouped by week, the following discussion will assist you. The grouping of dates into weeks has two requirements. First, the database file you are reporting from must be INDEXed on the date field that is being grouped on. Second, as the group expression in your REPORT FORM, you must have an expression that returns as its value the first day of the week for each date field. The expression is as follows: title: REPLACE version: 10 11 DR date: 10 Mar 1986 text: REPLACE ALL does not replace all records correctly if an index is in use and the key field is replaced. Only the first record and those that logically follow the new value will be replaced. This occurs because the index is automatically updated (in-place key updating) when it is edited. The record pointer moves to the record following the new position, not to the record following the old position. This can be illustrated in the example given below (the data file has five records with the field CHARS-C-1, and is indexed on this field): . LIST Record# CHARS 1 a 2 b 3 c 4 i 5 j . REPLACE ALL Chars WITH 'd' 3 records replaced . LIST 2 b 3 c 1 d 4 d 5 d The manual warns against block replacements to the key field. The correct procedure would be to REPLACE with no indexes in use, open the indexes with SET INDEX TO, and then REINDEX. title: RELEASE ALL, CLEAR MEMORY version: 10 11 DR date: 10 Mar 1986 text: RELEASE ALL and CLEAR MEMORY are not equivalent commands as the dBASE III manual states. CLEAR MEMORY clears all memory variables, regardless where they were initialized. RELEASE ALL, however, will release all memory variables except those declared PUBLIC or initialized in a nested command file. title: RELEASE, INCORRECT SYNTAX version: 10 11 DR date: 10 Mar 1986 text: The syntax "RELEASE ALL LIKE <skeleton>,<skeleton>" is incorrect but will not produce an error message. The correct syntax is either RELEASE <memvar list> or RELEASE ALL LIKE <skeleton>. You may use wildcard characters in the RELEASE ALL LIKE form of the command, but dBASE III will ignore any <skeleton> after the first comma. title: RAMDISKS version: 10 11 DR date: 10 Mar 1986 text: There are several options for users who wish to use a ramdisk in combination with dBASE III. a) The minimum drive size will have to be in excess of 181,000 bytes. The DBASE.OVL file for version 1.1 is 180,736 bytes. The total amount of RAM in your machine must be more than 440,000 bytes in order to do this. Additionally, if you are using a CONFIG.DB, it must be present on the drive where .OVL resides. b) Boot dBASE III from the ramdisk by calling for the DBASE.COM from the drive on which it resides. For example: drive D: is the ramdisk and the DBASE.COM is on the C: drive. C> D: D> C:DBASE 2. It may be a very useful area for procedure or command files to be run from, increasing the speed of processing. Prior to entering dBASE III, copy the appropriate files to the ramdisk. Once in dBASE III, SET the DEFAULT TO the ramdisk drive and proceed. 3. It is also useful as a small work area to manipulate utility and temporary files. The useage tips on getting the current directory or diskspace are good examples of where a small ramdisk would be extremely useful and time efficient. title: PUBLIC version: 10 11 DR date: 10 Mar 1986 text: PUBLIC is used to declare memory variables as global and to prevent their release when control is returned to the dot prompt. PUBLIC variables must be declared prior to being initialized, and once declared, these variables will be assigned a logical false value until initialized. PUBLIC variables can be re-declared as PUBLIC without losing the values already stored in them. In programming, declaring all variables as PUBLIC in the main routine would make dBASE III behave similar to dBASE II. However, there is one difference in dBASE III, PUBLIC variables can only be released by the CLEAR MEMORY, CLEAR ALL, and RELEASE <variable list> commands, but not the RELEASE ALL command. title: PROCEDURE version: 10 11 DR date: 10 Mar 1986 text: Calling Command Files from Procedures within dBASE III To call a command file from a procedure, you must follow a few rules. Rule 1: The command file cannot have the same name as any of the procedures in the file even if the extension is included as part of the filename. An attempt to do this will cause the inappropriate error message, "Unrecognized phrase/keyword in command." For example: * Proc_One.PRG PROCEDURE One * ---The next command will not work because * ---Two is a procedure in this file. DO Two.PRG RETURN * PROCEDURE Two * ---The next command will work. DO Three.PRG RETURN * EOF: Proc_One.PRG This can be avoided by renaming either the command file or procedure. To avoid this problem you might want to begin procedure names with a prefix that command files will not have. For instance, in the previous example the procedures could have been called P_One and P_Two. Rule 2: Once the command file is invoked from a procedure file, it must not DO another procedure in the procedure file. Instead, it should RETURN to the calling procedure. Otherwise, the called procedure will usually execute, but an error message will be displayed for a command line that does not exist. Rule 3: Internal procedure calls (that is, a procedure that calls either itself or another procedure in the same file) must be kept to eighteen nested calls or less. The nineteenth call attempt will return execution to the calling command file with no error message. title: PRIVATE version: 10 11 DR date: 10 Mar 1986 text: In dBASE III, all variables are PRIVATE to the routine in which they are initialized unless otherwise declared. Variables created at the dot prompt will automatically be PUBLIC no matter how they are declared. Declaring a variable PRIVATE in a command file hides any outer- level definition of a variable with the same name from the current routine. It also hides any deeper-level routines from viewing any outer-level definition of a variable with the same name. In the example below, programs B.PRG and C.PRG do not have access to variable X in program A.PRG. Program C.PRG, therefore, will display X with a value of 15 and not 10. Program A.PRG, however, will display X with the old value of 10 even after executing program B.PRG. * A.PRG x = 10 DO B ----------> * B.PRG ? x PRIVATE x RETURN x = 15 DO C ----------> * C.PRG RETURN ? x RETURN In programming, you will want to declare a variable PRIVATE in a subroutine if you do not want this variable to interfere with an outer-level variable having the same name. To illustrate the use of PRIVATE, the command files MAIN.PRG and SUB.PRG are listed below, with the displayed output. Notice that all the variables are released when MAIN.PRG returns control to the dot prompt. Also notice that the variables initialized in MAIN.PRG are PRIVATE in the memory display even though they are never explicitly declared. Lastly, notice that the value assigned to height in SUB.PRG is not returned to MAIN.PRG, but the value assigned to area in SUB.PRG is returned. This is because height is declared PRIVATE in SUB.PRG and area is not. LISTINGS: * MAIN.PRG * -------- area = 0 height = 304 ? "Before call to SUB:" ? "-------------------" DISPLAY MEMORY DO Sub ------------------> * SUB.PRG ? "After call to SUB:" * ------- ? "------------------" PRIVATE height DISPLAY MEMORY height = 30 RETURN area = 10 * 20 * height * EOF: MAIN.PRG ? "Inside SUB:" ? "-----------" DISPLAY MEMORY RETURN * EOF: SUB.PRG OUTPUT: Before call to SUB: ------------------- AREA priv N 0 ( 0.00000000) HEIGHT priv N 304 ( 304.00000000) 2 variables defined, 18 bytes used 254 variables available, 5982 bytes available Inside SUB: ----------- AREA priv N 6000 ( 6000.00000000) HEIGHT priv (hidden) N 304 ( 304.00000000) HEIGHT priv N 30 ( 30.00000000) 3 variables defined, 27 bytes used 253 variables available, 5973 bytes available After call to SUB: ------------------ AREA priv N 6000 ( 6000.00000000) HEIGHT priv N 304 ( 304.00000000) 2 variables defined, 18 bytes used 254 variables available, 5982 bytes available When DISPLAY MEMORY is entered from the dot prompt the following two lines will display: 0 variables defined, 0 bytes used 256 variables available, 6000 bytes available title: PARAMETERS, PASSING FIELDS version: 10 11 DR date: 10 Mar 1986 text: In the documentation concerning PARAMETERS when used in conjunction with the DO <filename> [WITH <parameter list>] command, page 4-76 of the version 1.0 manual states, "A passed parameter may be any legitimate expression." Also, in the Glossary (page 7-3) the definition for Expression is, "Expression may consist of a field, a memory variable, a function, a constant, or any combination thereof." However, when a DO is invoked with a field in the parameter list, dBASE III will give the message, "Variable not found." In order to use a field name in the parameter list, you must use the Alias -> Fieldname form. For example: USE Filea DO <Filename> WITH Filea -> Field1 will work, but the following will not. USE Filea DO <Filename> WITH Field1 title: NUMERIC INPUT OF LARGE NUMBERS version: 10 11 date: 10 Mar 1986 text: If a variable is initialized to zero, dBASE III does not allow input larger than 10 digits when using the @...GET command, even if the PICTURE clause is used. For example: x = 0 @ 5,5 SAY "Enter digits" GET x PICTURE "99999999999" * (There are eleven 9's) ---------- READ The display is: Enter digits 0 If an eleven digit value is entered, the display is: Enter digits ********** (10 asterisks) This can be avoided by initializing 'x' to a value greater than ten digits (such as, 1000000000). This problem does not occur if a field is used rather than a memory variable. title: NUMERIC FIELDS WITH DECIMAL PLACES version: 10 11 DR date: 10 Mar 1986 text: Although not documented, dBASE III expects the user to allow for a leading digit and a decimal point on numeric fields containing decimal places. For example, a numeric field of two decimal places should not be defined any smaller than four digits in length--one position for the leading digit, one position for the decimal point, and two positions for the two decimal places. If the structure for a numeric field does not allow for a leading digit (such as, a width of three and two decimal places), numeric input to the numeric field will always be stored as zero. Also, if other numeric fields follow this field, they might automatically be zeroed out when numeric data is entered to the first field. title: LOCATE AND CONTINUE version: 10 11 date: 10 Mar 1986 text: The LOCATE and CONTINUE commands cannot be used between two or more work areas at the same time. If a LOCATE is issued in one work area, then issued again in another work area, a CONTINUE in the original work area will result in a SKIP to the next record, not a CONTINUE. The following program segment illustrates how to LOCATE and CONTINUE between two data files. SELECT 2 USE Test SELECT 1 USE Test1 LOCATE FOR One > 1 DO WHILE .NOT. EOF() ? "FIELD Test1->One: " , One SELECT 2 LOCATE FOR one > 1 DO WHILE .NOT. EOF() ? "FIELD Test->One: ", One SKIP LOCATE NEXT 1000 FOR One > 1 ENDDO -------------- should be larger SELECT 1 than last record SKIP number in file. LOCATE NEXT 1000 FOR One > 1 ENDDO The dBASE III Reference Manual entry for MODIFY LABEL, states that "when you place several field names on one line of the LABEL contents screen, dBASE III eliminates the extra blank spaces and prints the label with only one space between fields." This should read, "when you place several field names, separated by commas, on one line, etc." Concatenations of fields appear as they always do. title: LABEL FORM COMMAND version: 10 11 date: 10 Mar 1986 text: If TRIM() functions are the only expressions on a line in a LABEL FORM, dBASE III will return "*** Execution error on SUBSTR(): start point out of range" when the LABEL FORM encounters a record in which all TRIMmed fields are blank. title: MODIFY STRUCTURE version: 10 11 DR date: 10 Mar 1986 text: The "Warning" in the documentation on page 4-73 of dBASE III version 1.00 and WARNING of page 4-80 of dBASE III version 1.10 should read as follows: WARNING: Although you may change field names and field lengths, if you change both at once, the data of the fields that have been modified will not be appended into the new structure. Note that in the ASSIST mode, the following screen message is not entirely true, "Information in the database file is preserved where field names remain the same." As noted above, if only field names are changed or only the length, the data is appended into the new structure. The correct procedure when both field name(s) and field length(s) need to be changed, is to modify the field name(s) first, and then re-enter MODIFY STRUCTURE and modify the field length(s). Also, note that deleting a field (with Ctrl-U) has the same effect as modifying the field length. Therefore, make deletions at the same time you make field length changes. title: MODIFY STRUCTURE version: 10 11 DR date: 10 Mar 1986 text: In MODIFY STRUCTURE, Ctrl-Home will bring up a menu on line 0 with the four choices listed below. Bottom Top Field # Menu They are selected with cursor control keys and <RETURN>. Bottom moves the cursor to the last field, Top to the first. Field # allows selection of a field number, then moves the cursor to it. Menu toggles the cursor control menu off and on. This feature is not documented under MODIFY STRUCTURE. title: MEMO FIELDS version: 10 11 date: 10 Mar 1986 text: (1) MEMO fields are used to contain up to 5,000 characters of text information that is to be associated with a database record. Information may be read into a MEMO field using Ctrl-K-R and written to text files using Ctrl-K-W. Information from MEMO fields can be displayed or printed by using LIST, DISPLAY, ?. The field must be specified with these commands. However, these commands cause the MEMO field to wrap at 50 columns. The REPORT FORM may be used to output MEMO fields with line widths of more or less than 50 characters. (2) PACKing a database file with memo fields will not decrease the amount of disk space used by the .DBT file. The command file below demonstrates how to remove the deleted records and free the unused disk space. SET DELETED ON USE Filea COPY TO Temp CLOSE DATABASE ERASE Filea.dbf ERASE Filea.dbt RENAME Temp.dbf TO Filea.dbf RENAME Temp.dbt TO Filea.dbt SET DELETED OFF (3) When APPENDing FROM a database file with a memo field, the target .DBT file will be at least as large as the source .DBT regardless of how many records are APPENDed. This is because the target .DBT file contains all the information that was contained in the source .DBT file. Be sure to note this any time you are moving records from one database file that contains memo fields to another. There is a danger of unexpectedly filling a disk when doing this operation. title: MACRO (&) SUBSTITUTION IN A FORMAT (.FMT) FILE version: 10 11 DR date: 10 Mar 1986 text: Macro (&) substitution will not work in a format (.FMT) file. For example: Structure for database: Macro.DBF Number of records: Date of last update: 5/01/85 Field Field name Type Width Dec 1 FLD01 Character 10 2 FLD02 Character 10 3 FLD03 Character 10 ** Total ** 30 * Program..: Macro.PRG * Note.....: This program will not display any field from * the database file. CLEAR PUBLIC month month = " " USE Macro ACCEPT "Enter two digits 01, 02, or 03: " TO month SET FORMAT TO Macro READ CLOSE FORMAT CLEAR RETURN Macro.FMT contains one line: @ 05,30 SAY Fld&month If the SET FORMAT TO Macro, READ, and CLOSE FORMAT command lines are removed and DO Macro.FMT is inserted in their place, the program will execute as expected and the field will be displayed. title: INPUT AND NEW MEMVARS version: 10 date: 10 Mar 1986 text: The INPUT command does not initialize a memory variable of any type if <RETURN> is pressed at its prompt. The dBASE III manual says this will produce a syntax error (page 4-58). What really happens is that a syntax error will result if the non-existent memvar is later referenced. title: CTOD() FUNCTION version: 10 11 DR date: 10 Mar 1986 text: The dBASE III Reference Manual does not clearly state that the CTOD() function will convert invalid dates to valid dates. The day is adjusted first. ? CTOD("02/29/85") 03/01/85 <------------ Extra day is added to month. ? CTOD("02/29/84") 02/29/84 <------------ Leap years are correct. If the month is invalid, it is divided by twelve and the year is adjusted. For example: ? CTOD("13/01/84") 01/01/85 <------------ Extra month is added to year. ? CTOD("12/32/84") 01/01/85 <------------ Extra day is added to month, extra month is added to year. ? CTOD("99/99/62") 06/23/70 title: FILE() FUNCTION version: 10 11 date: 10 Mar 1986 text: The FILE() function only searches the current directory. SET PATH TO does not affect this function. If other directories are to be searched, they must be supplied to the function. For example, * ---This will not find Data.dbf, if Data.dbf is in the * ---subdirectory ACCTS. SET QH TO DBASE ACCTS IF FILE( "DATA.DBF" ) DO Process ENDIF Workaround: * ---This method will work. mpath = " DBASE ACCTS " SET PATH TO &mpath IF FILE( mpath + "DATA.DBF" ) DO Process ENDIF title: DUPLICATE KEYWORDS IN CONFIG.DB version: 10 11 DR date: 10 Mar 1986 text: If two or more COMMAND = <value> lines are contained in the Config.DB file, only the last COMMAND will execute. This is true of any duplicate <keyword> = <value> entry in the Config.DB file, with the exception of DELIMITERS, which can legitimately have two entries. title: DISPLAY AND LIST version: 10 date: 10 Mar 1986 text: The DISPLAY and LIST commands are documented in the manual as not having a FIELDS clause as part of the syntax, while the ASSIST and HELP menu options assume the FIELDS clause is required. dBASE III will accept either syntax for these two commands. title: DEBUGGING TIP version: 10 11 date: 10 Mar 1986 text: The RETURN and CANCEL commands will release all PRIVATE memory variables when returning to the dot prompt. This can make debugging difficult with versions 1.0 and 1.1 as you may want to check the status of variables used by the program. The following debugging utility can be set up as a command file. This utility, called Dot.PRG, will allow you to interactively enter commands, such as LIST MEMORY and LIST STATUS. You can insert the command "DO Dot" at various problem points in your program. When this command is encountered, you will be able to enter interactive commands without destroying the current environment of the program at runtime. Once the program is fully debugged, you can remove the "DO Dot" command lines. * Dot.PRG DO WHILE .T. ACCEPT 'DOT ' TO command IF LEN( TRIM(command) ) = 0 EXIT ENDIF &command ENDDO RETURN title: DATES THAT ARE BLANK version: 10 11 DR date: 10 Mar 1986 text: CTOD() and DTOC() are intended to be inverse functions. That is, if DTOC(date) = char, then CTOD(char) = date. This is true in all circumstances except when the date is blank and the character string is " / / ". To detect a blank date, you must use the DTOC() function rather than CTOD(). For example: reg_date = CTOD("11/09/84") ? reg_date = CTOD("11/09/84") .T. ? DTOC(reg_date) = "11/09/84" .T. * ---With a blank date the following occurs: blank_date = CTOD(" / / ") ? blank_date = CTOD(" / / ") .F. ? DTOC(blank_date) = " / / " .T. As is evident from the example, the blank date is handled differently than the non-blank date. title: DATE CONVERSION FROM DBASE II version: 10 11 DR date: 10 Mar 1986 text: The dBASE BRIDGE manual (pages 23-24) lays out an elaborate scheme for converting dBASE II "dates" to dBASE III date fields. A much easier way is to simply convert the dBASE II database file to a dBASE III file and modify the structure from character to date field. All dates stored in a dBASE II character field as "MM/DD/YY" will directly convert to a dBASE III date field. title: CREATE/MODIFY REPORT version: 10 11 DR date: 10 Mar 1986 text: When you get the error message "Internal error - bucket overfilled" while in CREATE REPORT or MODIFY REPORT, you have too many characters in the report. The maximum number of characters, or bucket size, is 1,440 bytes. This includes the number of characters in the following list: Report heading - plus one byte for each line Subtotal heading(s) - plus one byte for each line Subtotal expression(s) - plus one byte for each expression Field heading(s) - plus one byte for each line Field expression(s) - plus one byte for each expression The extra byte is a null terminator for each expression and heading. When there are multiple lines in a heading, dBASE III separates them with a semicolon in the .FRM file. title: COPY STRUCTURE EXTENDED / CREATE FROM version: 10 date: 10 Mar 1986 text: COPY STRUCTURE EXTENDED and CREATE FROM are fully implemented in dBASE III although not documented. A brief description is given below. 1) COPY STRUCTURE EXTENDED creates a file in which the field names become the contents of one record. The syntax for this COPY option is: COPY STRUCTURE EXTENDED TO <new file> 2) CREATE FROM forms a new database (.DBF) file in which the structure is determined by the contents of a file created with COPY STRUCTURE EXTENDED. The syntax is: CREATE <new file> FROM <structure extended file> title: COPY FILE <SOURCE FILENAME> TO <TARGET FILENAME> version: 10 11 DR date: 10 Mar 1986 text: The COPY FILE command copies files in 512 byte blocks; whereas, the COPY TO command will copy a .DBF file until the end-of-file. Therefore, the COPY FILE command will usually create a slightly larger file than the COPY TO command. However, the COPY FILE is faster. title: COPY TO <FILENAME> [SDF/DELIMITED [WITH <DELIMITER>]] version: 10 11 DR date: 10 Mar 1986 text: (1) COPY TO <filename> DELIMITED does not enclose logical fields with the specified delimiters. Numeric and date fields are also treated this way. Date fields go out in the format YYYYMMDD. (2) COPY TO <filename> DELIMITED WITH , encloses the character fields in commas and separates the fields with another comma. This command behaves differently from dBASE II as shown below: In dBASE II: . USE file1 . COPY TO file2 DELIMITED WITH , will result in: SANTA,CLAUS,NORTH POLE,ALASKA In dBASE III: . USE file1 . COPY TO file2 DELIMITED WITH , will result in: ,SANTA,,,CLAUS,,,NORTH POLE,,,ALASKA, title: CLOSING DATABASE FILES version: 10 11 DR date: 10 Mar 1986 text: Do not swap data disks without first closing all the open files on the original disk. Not doing so will cause the loss of data in buffers, and will also write a new entry in the directory of the new disk. USE will close the currently SELECTed database file and CLOSE DATABASES will close all database files in all work areas. CLEAR ALL also closes all open database files and will also release all memory variables. QUIT closes all files, releases all variables, and exits dBASE III. Choose one of these commands to close your files before swapping data disks. title: APPEND FROM <FILENAME> [SDF/DELIMITED [WITH <DELIMITER>]] version: 10 date: 10 Mar 1986 text: The DELIMITED form of the APPEND FROM command should be documented as having a WITH clause. WITH is not mentioned in the reference section. Below are a few examples: Example 1. To read a comma delimited file in which the character strings are enclosed in double quotes: APPEND FROM <filename> DELIMITED or APPEND FROM <filename> DELIMITED WITH " Example 2. To read a comma delimited file in which the character strings are enclosed in single quotes: APPEND FROM <filename> DELIMITED WITH ' Example 3. To read a comma delimited file in which the character strings are not enclosed at all: dBASE III CANNOT READ A FILE OF THIS FORMAT! Also, the syntax of the APPEND command does not include a WHILE option as the manual indicates. The correct syntax is APPEND FROM <file name> [FOR <condition>] [SDF/DELIMITED [WITH <delimiter>]] APPEND FROM <textfile> SDF expects records in the text file to be terminated with a carriage return/line feed (0DH 0AH) pair, in this order. If the order is reversed (0AH 0DH), dBASE III ignores the character following the carriage return. This causes the first character of every record (after the first record) to be missed in the resultant database file. title: @ SAY PICTURE version: 10 11 DR date: 10 Mar 1986 text: To display a dollar-sign character ("$") in front of a numeric value and not have the possibility of a lot of "$"s filling the blank areas, do the following: * ---To display a single "$". STORE 123.56 TO num @ 10,10 SAY "$" @ 10,11 SAY num PICTURE "99,999.99" This will generate: $ 123.56 * ---The other option available is: STORE 123.56 TO num @ 10,10 SAY num PICTURE "$$,$$$.$$" This will generate: $$$123.56 title: @ GET AND READ version: 10 11 date: 10 Mar 1986 text: (1) If an attempt is made to @...GET memvar PICTURE "999.99" and the memory variable is not initialized with the number of decimal places specified in the PICTURE clause, the GET display will not show the decimal digits for input. Entering a decimal point will exit the GET. For example: * ---Set up numeric input. num = 0 @ 10,10 SAY "Enter number " GET num PICTURE "999.99" READ * * ---After entering a decimal point during the READ, * ---the GET will display the following: Enter number : 0. : To properly input numeric memory variables with decimal digits using @...GET...PICTURE, initialize the memory variable with the number of decimal digits used in the PICTURE clause. For example: * ---The following command line assigns num with * ---the same number of decimal digits as found * ---in the PICTURE clause. num = 0.00 @ 10,10 SAY "Enter number " GET num PICTURE "999.99" READ (2) When using @...GET and READ certain keys will terminate the READ. The following table shows which keys do so and where in the pending GETs the key will terminate the READ. Key: The READ will terminate at: ----------- --------------------------- Backspace First character of first GET Left arrow First character of first GET Right arrow Last character of last GET Up arrow First GET Down arrow Last GET Esc Anywhere F1 Anywhere Ctrl-[ Anywhere Ctrl-Q Anywhere Ctrl-W Anywhere Ctrl-Home Anywhere Ctrl-End Anywhere PgUp Anywhere PgDn Anywhere Ctrl-PgUp Anywhere Ctrl-PgDn Anywhere Alt 0-9 Anywhere RETURN to continue or <H>elp: 63 item(s) found